1 SYSTEM AND METHOD FOR SIMULATING LUBRICATING OIL TESTING 

2 

3 COPYRIGHT NOTICE AND AUTHORIZATION 

4 

5 This patent document contains material which is subject to copyright 

6 protection. 
7 

8 © Copyright 2004. Chevron Oronite S.A. All rights reserved. 
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10 With respect to this material which is subject to copyright protection. 

1 1 The owner, Chevron Oronite S.A., has no objection to the facsimile 

12 reproduction by any one of the patent disclosure, as it appears in the 

13 Patent and Trademark Office patent files or records of any country, but 

14 otherwise reserves all rights whatsoever. 
15 

16 I. FIELD OF THE INVENTION 

17 

18 The invention relates to computer-implemented process and system for 

19 simulating the results of actual lubricating oil tests. 
20 

21 II. BACKGROUND OF THE INVENTION 

22 

23 Lubricating oils intended for use in internal combustion engines are a complex 

24 mixture of various components, including base oil, performance-enhancing 

25 additives, viscosity modifiers, and pour point depressant. Before a new 

26 lubricating oil blend can be sold, it must meet various industry-established 

27 performance/qualification tests. The results of the tests must be consistent 

28 with the labeling and marketing used when selling the new blend. The 

29 qualification tests include laboratory bench tests and internal-combustion 

30 engine tests. 
31 

32 Tests include tests for viscosity, seal compatibility, oil oxidation, piston 

33 deposit, cam or lifter wear, and ring sticking. Such tests require use of 
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1 expensive laboratory and human resources. Example costs of such tests are 

2 $80,000 for the Daimler Chrysler OM441 LA or Mack T-10 engine tests and 

3 $35,000 for the Daimler Chrysler OM602A engine test. 
4 

5 With available methodologies, product qualification engineers are only able to 

6 prepare test plans using spreadsheet tools like Excel in a very simple way. 

7 Test plans are not systematically available because of a lack of tool for 

8 preparing them. Only very few test models are available for pass/fail 

9 prediction because data preprocessing is not available in an automated 

1 0 system. The concept of simulating several test models together has not been 

1 1 implemented. Code of practice issues can only be checked when faced with 

12 actual problems without much anticipation. The level of input data and 

13 information to be used by the product qualification engineer is overwhelming 

14 when preparing an efficient test plan. With known methods and tools, it is 

1 5 impossible for an engineer to take all of this data and information into account 

16 in a rational way. This has become even more true in the past 5 years due to 

17 the ever increasing complexity of the lube oil qualification environment. No 

18 known solutions exist that makes use of a rule engine for code of practice 

1 9 guidelines management or that simulates and optimizes complete lube oil test 

20 programs. 
21 

22 It would be desirable to have a computer-implemented simulator which could 

23 include models of the qualification tests. Such a simulator would predict the 

24 likely outcome if the lube blend in question were submitted to the actual 

25 qualification tests. By using such a simulator, the time and cost of developing 

26 new blends could be reduced. The invention provides such a simulator. 
27 

28 III. SUMMARY OF THE INVENTION 

29 

30 The invention includes a method of simulating and optimizing qualification 

31 testing of lubricating oil products, the method including: passing a plurality of 

32 lubricating oil product characteristics to a simulator engine, where the 

33 simulator engine includes a plurality of simulated qualification tests and 
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1 processing the lubricating oil product characteristics in one or more of the 

2 simulated qualification tests, where the output of each simulated qualification 

3 test includes a probability of passing indicator for indicating the probability that 

4 a lubricating oil product have the inputted characteristics would pass an actual 

5 qualification test; passing an input of the plurality of lubricating oil product 

6 characteristics, the probability of passing indicator from each simulated 

7 qualification test, and a proposed test sequence of a plurality of qualification 

8 tests to a strategy simulator engine and processing the input to determine a 

9 probability of passing indicator, cost and time duration of the proposed test 
10 sequence. 

11 

12 Another embodiment of the invention includes a system for simulating and 

13 optimizing qualification testing of lubricating oil products, the system including: 

14 a CPU; a memory operatively connected to the CPU, the memory containing 

15 a program adapted to be executed by the CPU and the CPU and memory 

16 cooperatively adapted for simulating qualification testing of lubricating oil 

1 7 products; a simulator engine code segment embodied on a computer- 

18 readable medium configured and adapted for receiving as input a plurality of 

19 lubricating oil product characteristics, where the simulator engine includes a 

20 plurality of simulated qualification test code segments, and configured and 

21 adapted for processing the input of lubricating oil product characteristics in 

22 one or more of the simulated qualification test code segments, where the 

23 output of each simulated qualification test code segments includes a 

24 probability of passing indicator for indicating the probability that a lubricating 

25 oil product have the inputted characteristics would pass an actual qualification 

26 test; a strategy simulator code segment embodied on a computer-readable 

27 medium configured and adapted for receiving as a second input the plurality 

28 of lubricating oil product characteristics, the probability of passing indicator 

29 from each simulated qualification test code segment, the plurality of 

30 lubricating oil product characteristics, and a proposed test sequence of a 

31 plurality of qualification tests, and processing the second input to determine a 

32 probability of passing indicator, cost and time duration of the proposed test 

33 sequence. 
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1 These and other features and advantages of the present invention will be 

2 made more apparent through a consideration of the following detailed 

3 description of a preferred embodiment of the invention. In the course of this 

4 description, frequent reference will be made to the attached drawings. 
5 

6 IV. BRIEF DESCRIPTION OF THE DRAWINGS 

7 

8 Figure 1 depicts in one embodiment a schematic system diagram for the 

9 invention. 
10 

1 1 Figure 2 depicts in one embodiment a table for use in the Rules Engine 

1 2 aspect of the invention. 
13 

14 Figure 3 depicts in one embodiment a schematic layer-view system diagram 

1 5 for one illustrative implementation of the invention. 
16 

17 Figure 4 depicts in one embodiment a more detailed schematic system 

18 diagram of the Data Management component for one illustrative 

19 implementation of the invention. 
20 

21 Figure 5 depicts in one embodiment a more detailed schematic system 

22 diagram of the user interface component for one illustrative implementation of 

23 the invention. 
24 

25 Figure 6 depicts in one embodiment a schematic process flow diagram with a 

26 logical view of the data for one illustrative implementation of the invention. 
27 

28 Figures 7 and 8 depict in two different embodiments schematic diagrams of 

29 the variations of tested complete lubricant composition used as part of a test 

30 strategy. 
31 

32 Figures 9-17 depict in one embodiment a schematic process logic flow 

33 diagram for use in the strategy simulator aspect of the invention. 
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1 Figures 18-28 depict in one embodiment a graphical user interface for some 

2 aspects of the system of the invention. 
3 

4 V. DETAILED DESCRIPTION OF THE DRAWINGS AND PREFERRED 

5 EMBODIMENTS 
6 

7 A. Introduction 
8 

9 The following discussion and figures include a general description of a 

10 suitable computing environment in which the invention may be implemented. 

1 1 While the invention may be described in the general context of a system and 

12 an application program that runs on an operating system in conjunction with 

13 general purpose computers, an internet, and web application, and email 

14 servers and clients, those skilled in the art will recognize that the invention 

15 also may be implemented in combination with other program modules. 

16 Generally, program modules include routines, programs, components, data 

1 7 structures, etc. that performs particular tasks or implement particular abstract 

18 datatypes. 
19 

20 Moreover, those skilled in the art will appreciate that the invention may be 

21 practiced with other computer system configurations, including hand-held 

22 devices, multiprocessor systems, microprocessor-based or programmable 

23 consumer electronics, minicomputers/servers, workstations, mainframe 

24 computers, and the like. 
25 

26 The invention may also be practiced in distributed computing environments 

27 where tasks are performed by remote processing devices that are linked 

28 through a communications network. In a distributed computing environment, 

29 program modules may be located in both local and remote memory storage 

30 devices. 
31 

32 Then invention generally relates to a simulation system for qualifying 

33 lubricating oils. The process aspects of the invention are a series of process 
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1 steps utilizing, in whole or in part, the system herein and variations thereof. As 

2 would be clear to one skilled in the art, the process steps can be embodied in 

3 part as code for a computer program for operation on a conventional 

4 programmed digital computer, such as a client and server. The program code 

5 can be embodied as a computer program on a computer-readable storage 

6 medium or as a computer data signal in a carrier wave transmitted over a 

7 network. 
8 

9 B. Illustrative Benefits of the Invention 
10 

1 1 The System helps solve the following problems which relate to qualifying lube 

12 oils: automatic data conditioning, automatic test modeling, systematic 

13 checking of code of practice rules, automatic strategy simulator for risk 

14 analysis with probability of success of a potential test program along with 

1 5 average cost and duration, automatic strategy optimization for best trade off 

16 between program cost, duration, probability of pass and product cost. The 

17 System allows complete program simulations for better decision making and 

18 risk assessment. 
19 

20 C. Illustrative Implementation Environment 
21 

22 An illustrative implementation environment includes: a Java virtual machine, 

23 (e.g., JDK 1.3) to support all Java software components. All System 

24 components are optionally written in full Java, except for external libraries. A 

25 web server (e.g., Apache) to interpret the http code generated by the JSP 

26 pages within the System pseudo-component GUI. A servlet engine (e.g., 

27 Resin or Tomcat) to execute the Java Server Pages of the System pseudo- 

28 component GUI. A database (e.g., ORACLE) that handles all persistent data 

29 used within the System. 
30 

31 Actual access to DATA within the System is taken care of by a unique 

32 component (DAT), and this access is performed using the JDBC API. Third 

33 parties software components or libraries such as STORM™ (from software 
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1 vendor Elseware) for neural networks and HUGIN™ (from software vendor 

2 HUGIN) for Bayesian networks and Blaze Advisor™ (from software vendor 

3 Fair Isaac) as code of practice rule engine. An external 

4 Extract/Transform/Load ("ETL") procedure, built, e.g., with Informatica brand 

5 software, is in charge of filling the System database with data extracted and 

6 transformed from past physical qualification tests databases and other 

7 sources. The ETL tool is used to extract data from one or more source DB, 

8 transform the data and load it on a target DB. 
9 

10 D. Algorithms 
11 

12 Suitable algorithms include Bayesian and Neural Networks, Monte Carlo 

13 simulator, Non Dominated Sorting Genetic Algorithm, and mixed RETE/Prolog 

14 like Algorithm for the rule engine. Details on each can be found in the 

1 5 publications in the field. 
16 

17 E. Overview of System Architecture 
18 

19 The functional architecture of the System is summarized in the picture below. 

20 the System is comprised of five main functional components: Data 

21 Representation (also called Data Collapsing), Model Building, Model 

22 Execution, Compliance Evaluation, and Simulation. These components do not 

23 necessarily correspond to a software module depending on how the System is 

24 implemented. For instance, the data collapsing function may optionally be 

25 used in several software modules in the System. This decomposition is the 

26 most appropriate to understand how the System works, without going into 

27 potential implementation details. 
28 

29 F. The User Point of View 
30 

31 In order to benefit from the System risk analysis derived from the Monte Carlo 

32 simulation of a test program, the PQ engineer has to feed some information 

33 into the System. Typically, for a standard program, 1 or 2 hours of preliminary 
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1 work are required to enter the variants and the strategies definition. By 

2 "variants" we mean here the set of finished oils that may be used during a 

3 program. This may require a slight change of work habits for the PQ 

4 engineers. Indeed, it will be necessary to consider all potential options in 

5 terms of formulation before starting a program, or at least to be as exhaustive 

6 as possible. The same effort is needed for the test plan. A strategy is typically 

7 an ordered sequence of tests that would have to be passed for the program to 

8 be successful. But defining a strategy requires also to consider alternatives 

9 (e.g., what if this test fails more than 3 times.) This new way of working may 

10 seem more like a constraint, but considering the alternatives is the basis of 

1 1 any rational risk analysis process. 
12 

13 G. Data Representation 
14 

15 In order to simulate a program test, the System needs creating input/output 

16 models in the form "Finished Oil | Performance". A finished oil is typically 

17 defined by a list of 10 to 20 constituents: additives, viscosity improver, pour 

18 point depressant, and base stocks. A test result is defined by one or more 

19 measurements performed after using the finished oil. For instance, in an 

20 engine test, some wear measurements will be performed after operating the 

21 engine for 2-300 hours. If one tries to organize all the data available for one 

22 particular test into a table, one would typically have one column per 

23 constituent, and one line per test run. But the potential number of constituents 

24 is very large (i.e., more than the number of base stocks). This means that the 

25 table would be very sparse. No statistical modeling technique can infer 

26 anything from such data. 
27 

28 However, it's known that the name of one particular constituent is not 

29 important, its properties are. We know that the group or the total polar dosage 

30 of a base oil may have some impact, whatever the manufacturer of the oil. 

31 That was one of the major tasks in the System: reach an agreement among 

32 experts to define a data representation independent of constituent names, but 

33 rather based on generic descriptors. We call this representation a "data 

-8- 



1 collapsing". The data collapsing can be implemented via various known 

2 methodologies. This representation may evolve. The System has been 

3 designed to be independent of the data collapsing used. 
4 

5 H. Model Building 
6 

7 All the System models are input/output models in the form 

8 "Finished Oil | Performance". One of the benefits of the System is that test 

9 models merge two sources of knowledge: expert knowledge and empirical 

10 knowledge. Formulators are the experts that provide the qualitative 

1 1 knowledge for the System models. During the System development phase, 

12 more than 120 interviews of formulators have been conducted, to gather their 

1 3 beliefs on the main factors driving the test results. 
14 

1 5 Typical number of samples for an engine test of interest (i.e. an engine test 

16 which is not obsolete) is 100-200. And even though the data representation 

17 for a given formulation has been made compact (as discussed above), 

18 adjusting a model with potentially 90 input variables on 100 samples is very 

19 likely to yield to over fitted models. This is why formulators , expertise is 

20 fundamental to keep model building focused and to obtain robust models. 

21 Most System models for engine tests will be built using this type of hybrid 

22 knowledge. For some models, typically bench tests, when a significant 

23 number of test runs are available, we consider the use of purely data-driven 

24 procedures. 
25 

26 I. User Inputs and Model Execution 
27 

28 Figure 1 shows the general architecture of the System. For a detailed 

29 discussion of Figure 1 see the discussion of Figures section below. The PQ 

30 engineer input, typically the finished oil he/she plans to use, and the test plan 

31 he/she has in mind. Preferably, the PQ engineer updates the test plan 

32 monitoring information in the System. Other sources of inputs are shown in 

33 Figure 1 , e.g., lube oil composition formulator expertise on variable selection. 
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1 The System intermediate results include test models, finished oil in V90. 

2 Output is Finished oil test performance and test program cost and timing 

3 probabilities. 
4 

5 The System modules are shown in Figure 1 . Model execution is the core of 

6 the System simulator. During a simulation, the finished oils that have been 

7 assigned to a program by the PQ engineer will actually go through virtual 

8 tests. For a finished oil, going through a virtual test precisely means: The 

9 formulation of the finished oil is transformed into a vector of variables x, 

10 according to the data collapsing used. This vector is then input to the test 

1 1 model, which computes an output y=f(x). This output is usually a vector since 

12 a test usually has more than one outcome being monitored. This output is not 

1 3 the final outcome of the virtual test. 
14 

1 5 Since we want to reproduce the partially random behavior of a test, the final 

16 outcome is sampled according to a random distribution. The mean of the 

17 distribution is the output of the test model, and its variance is the residual 

1 8 variance of the test model. In other words, this means that if the model shows 

19 poor explanatory power (high residual variance), the final outcome of the 

20 virtual test will be almost purely random. On the other hand, if the test model 

21 is accurate, final outcome of the virtual test will be almost deterministic. The 

22 form of the distribution used for sampling will depend on the quality of the 

23 empirical distribution observed. Usually, this will be either normal or lognormal 

24 distribution. 
25 

26 J. Compliance Evaluation 
27 

28 Compliance evaluation relates to the strategy aspect of the System. For a 

29 PQ engineer, designing a virtual test program also involves considering when 

30 he/she will implement a minor formulation modification. For instance: Start the 

31 test plan with formulation OR-F1 . If the XUD1 1 sequence clearly fails more 

32 than 3 times, switch to a boosted formulation OR-F2. In complex simulations, 

33 it may become necessary to implement successive formulation modifications. 
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1 In such cases, the formulations used at various stages of the program may be 

2 incompatible with respect to the codes of practice, such as ATC, or ATI EL. 
3 

4 A specific module in the System is in charge to analyze all strategies in order 

5 . to identify formulations changes that would be in violation of the codes of 

6 practice. For the PQ engineer use, this module first produces a report 

7 showing all potential conflicts. This is particularly useful to identify mistakes in 

8 the formulations definition. But the main use of this module is to control the 

9 changes of formulation during the simulation. 
10 

1 1 When a change of formulation is implemented during a simulation, the System 

12 compliance module will make sure that all tests that have been considered 

13 "Pass" in the previous steps of the simulation would still hold with the new 

14 formulation. The System compliance module is also used for suggesting 

1 5 VGRA, and for checking the conformity of base oil interchanges. 
16 

17 K. Program Simulation 
18 

19 Program simulation (also referenced as "Monte Carlo simulator") is a core 

20 component of the System. The Monte Carlo simulator virtually runs several 

21 thousands times the test plan strategy that was defined by the PQ engineer. 

22 For each run, all the instructions specified in the strategy are respected: order 

23 of tests, tests run in parallel, formulation changes, and other aspects. A single 

24 run of the test plan can yield to two situations: The test plan is successful: 

25 this means that all tests were finally "pass" (this may have required several 

26 repeats, formulation changes, etc.) or the test plan fails: this can happen only 

27 when one limitation has been set (either to the number of repeats allowed, the 

28 test plan budget, or the test plan timing). 
29 

30 Based on several thousands of runs, the System can compute various 

31 statistics: e.g., Pass rate, Average cost and timing, Distribution of cost and 

32 timing, and Most probable successful variant. It is important to understand the 

33 statistical nature of this inference, which we describe here as a causal graph. 
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1 The program final result is essentially random. Its distribution can only be 

2 shifted in more favorable regions. A successful strategy involves the 

3 formulators' input of a formulation designed with a sufficient probability of 

4 success and the PQ engineers' input of a test strategy which can reduce the 

5 cost or timing on average. 
6 

7 L. Detailed Description of the Figures 
8 

9 The invention and exemplary implementations thereof will now be described 

10 with reference to the figures. Figure 1 depicts in one embodiment a schematic 

1 1 system diagram for the invention. Inputs from product engineers, who are 

12 intended users/operators of the system, include the proposed finished oil 145, 

1 3 the test plan 1 50, and optionally updates to the test plan obtained by 

14 monitoring of actual test results 190. Additional inputs include formulator 

1 5 expertise on variable selection for models 115, data from a database of 

16 physical tests 105, and codes of practice 180. Intermediate results of the 

17 system include test models 120, finished oil in V90 format 130 (i.e. 90 

18 variables in a collapsed format), and strategy compliance analysis 175. 
19 

20 Final output of the system includes Finished Oil Test Performance 

21 Estimate 140 and Test Program Cost and Timing Estimates 165. System 

22 modules are Test Model(s) 120 (set of individual test simulators) and Program 

23 Simulation module 160 (a strategy simulator). The system modules are 

24 described in more detail in this below. 
25 

26 The Program Simulation module 160 takes as input data describing an actual 

27 or potential (i.e., virtual) new lube blend. The input data includes as many as 

28 90 parameters such as dispersant level, antiwear level, additive package treat 

29 rate, base stock level, VI improver level, Pour Point Depressant, base oil 

30 blend viscosity, kinematic viscosity, HTHS viscosity, sulfated ash etc .... This 

31 data is passed to the Program Simulation module 160, passed through one or 

32 more qualification Test Models 120 within the Program Simulation module 

33 160, and the output includes the probability that the lube blend will pass one 
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1 or more qualification tests of interest, i.e., Test Program Cost and Timing 

2 Estimates 165. 
3 

4 The qualification Test Models 120, the key ones being the Engine and Bench 

5 test models, are constructed in software using advanced statistical methods. 

6 In particular, they may be based on Bayesian and Neural Network modeling 

7 techniques. Other techniques may also be suitable. The Bayesian and/or 

8 Neural Network and/or other modeling techniques used in the invention may 

9 be developed internally or obtained in a software package licensed from an 

10 outside vendor. The models are constructed, in part, by inputting several 

1 1 years of actual qualification test data, preferably 15 years or more, into a 

12 Model Building engine 110, e.g., one using the previously mentioned 

13 Bayesian and/or Neural Network modeling techniques. 
14 

15 The Program Simulation module 160 takes as input data describing the test 

16 sequence planned as well as the minor formulation changes envisaged during 

17 the test plan execution, i.e., collectively making up Testing Strategy 150. 

18 Using Monte Carlo techniques, the Program Simulation module 160 produces 

1 9 output that may also include expected cost and duration necessary to perform 

20 the actual tests to a successful completion, i.e., Test Program Cost and 

21 Timing Estimates 165. 
22 

23 During the simulation, the Program Simulation module 160 is constantly 

24 checking that the Testing Strategy 150 executed will be compliant with the 

25 current "Codes of Practice" 180 for lubricant oil testing. To do so, the 

26 invention includes a "Rules Engine" (not shown) which may be internally 

27 developed or obtained from an outside vendor. A Rules Engine permits a 

28 user of the invention to establish desired Codes of Practice rules 180 using a 

29 user-friendly, plain-English interface. The Rules Engine then converts the 

30 plain-English rule into the desired computer-programming language, e.g., 

31 Java. Example rules a user may wish to create include, e.g.: 
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1 • Rule 1 : (ATC; h.1 ) No decrease in treatment level of either the entire 

2 performance additive package or its individual components is allowed, 

3 except within the context of permissible rebalances. 
4 

5 • Rule 2: (ATC; h.3) One new component addition (separate from 

6 permissible rebalances) is allowed, subject to its final level being no 

7 more than 10% by mass of the final performance additive package. 
8 

9 • Rule 3: The KV@1 00C of the finished oil of the read across grade must 
10 be greater than or equal to that of the tested grade. See Figure 2. 

11 



12 Another aspect of the invention is it can establish compliance with "Code of 

13 Practice" agreements. Code of Practice agreements are signed by lubricant 

14 manufactures or lubricant component manufacturers on a yearly basis. The 

15 invention allows proof of compliance by systematically checking all the related 

16 Code of Practice rules applying to a simulated program in terms of formulation 

17 minor modifications, viscosity grade read across and base oil interchange 

18 guidelines. 
19 

20 Other required and/or optional components of the invention include a strategy 

21 optimizer (not shown), which explores the space of feasible strategies with 

22 techniques such as genetic algorithms, or simulated annealing. The optimizer 

23 proposes a candidate strategy based on test plan requirements and user 

24 objectives, such as cost or duration. 
25 

26 The invention may be built to operate on any conventional computer platform, 

27 but preferably is a web-based application accessible by any authorized user 

28 having a web browser connected to the Internet or company-internal Intra-net 

29 on which an application server containing the invention resides. 
30 

31 The invention may be constructed using conventional software engineering 

32 methods. Potential users of the invention will be Product Qualification 

33 personnel. New lube blend developers may also be users. Utilizing the 
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1 system of the invention, from within one piece of software, the complete 

2 product qualification process can be both simulated and optimized. 
3 

4 Figure 3 depicts in one embodiment a schematic layer-view system diagram 

5 for one illustrative implementation of the invention. The layers are Client layer 

6 300, Presentation Server layer 310, Application Server layer 330, Data Server 

7 layer 370, and Production Data Server layer 380. Client layer 300 includes 

8 Navigator 305 comprising a user interface, preferably a graphical user 

9 interface ("GUI"), optionally a web browser. Presentation Server layer 310 

10 includes GUI (optionally Java Server Pages) 315 operatively connected to 

1 1 Navigator 305, GUI (optionally powered Java Server Pages) 315, operatively 

12 connected to System QUI (optionally a Java Package) 320, operatively 

13 connected to Reporting (optionally a Java component) 325. 
14 

15 Application Server layer 330 includes Model Builder (optionally a Java 

16 Component) 335 operatively connected to each of the following: Bayesian 

17 networks software (e.g., Hugin brand) (optionally an external Java API) 340 , 

18 neural networks software (e.g., Storm brand) (optionally an external Java 

19 API), and Data Management (optionally a Java component) 350. Data 

20 Management 350 is operatively connected to both System Foundation 

21 Package (optionally a Java Package) 355, and Strategy Simulator (optionally 

22 a Java Component) 360. Strategy Simulator 360 is operatively connected to 

23 both System GUI 320 and Reporting 325. 
24 

25 Data Server layer 370 includes System Database 375 operatively connected 

26 to ETL Procedure 375 in Production Data Server layer 380. Production Data 

27 Server layer 380 also includes Other Sources database 390 and past physical 

28 lube oil tests database 395, each operatively connected to ETL Procedure 

29 380. 
30 

31 Figure 4 depicts in one embodiment a more detailed schematic system 

32 diagram of the Data Management component for one illustrative 

33 implementation of the invention. Simplified views of the Presentation layer 
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1 310 (Figure 3) and Application Server layer 330 (Figure 3) are repeated in this 

2 Figure 4 in JSP 315, GUI 320, Modeling Services 335, Simulation Services 

3 360, Reporting Services 325, and data and Objects Management & Services 

4 350. The emphasis in this figure is the more detailed view of the data and 

5 Objects Management & Services 350 (also called "Data Management module 

6 350"). In one embodiment, the data managed in the Data Management 

7 module 350 is stored in a hierarchical/tree directory format, i.e., with a root 

8 directory, sub-directories, and sub-sub-directories. 
9 

10 The term directory as used here is by way of example only and is intended to 

1 1 indicate any available programming construct or other methodology for 

12 organizing data, files, or records. Higher levels of the directory include 

13 Common Workspace objects 405 and User Workspaces objects 410. Under 

14 each respective workspace are Oils objects 41 5, Components objects 420, 

15 Program objects 425, and Variant objects 430. Under Program objects 425, 

16 are Strategy objects 435. Load Common Objects on System Start module 

17 445 and Save Objects Upon Request module 440 provide the functions 

18 indicated by the name of each module. 
19 

20 Figure 5 depicts in one embodiment a more detailed schematic system 

21 diagram of the user interface component for one illustrative implementation of 

22 the invention. Figure 5 repeats modules shown in Figures 1, 3, or 4 and 

23 additionally shows point of interface between various users and the system. 

24 The roles of the different users are also listed. The roles of the Data 

25 administrator 505 include Maintain database and Maintain Codes of Practice. 

26 The Data administrator 505 interfaces with the system via ETL Procedure 

27 module 385. 
28 

29 The roles of the GUI Model Builder 510 include Define model architecture 

30 (formulators input), Define model variables, build models, and access models. 

31 The GUI Model Builder 510 interfaces with the system via Model Building 

32 module 335. The roles of the GUI Product Quality ("PQ") Engineer 515 

33 include Define Programs, Define Finished Oils (formulators input), Define 
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1 Strategies (Test Plans and Alternatives), and Use Models. The GUI PQ 

2 Engineer 51 5 interfaces with the system via the Monte Carlo Simulator 

3 module (also called "Strategy Simulator") 360. 
4 

5 Figure 6 depicts in one embodiment a schematic process flow diagram with a 

6 logical view of the data for one illustrative implementation of the invention. As 

7 in Figure 5, this figure shows the users and their points of interface with the 

8 system. Product Quality engineer 515 inputs a test program 415 and oil 420 

9 for entry into system database 375. These are passed to strategy simulator 

10 360 along with model 120. The output is the probabilities of time, cost, and 

1 1 likelihood of passing the test program 165. 
12 

13 Figures 7 and 8 depict in two different embodiments schematic diagrams of 

14 the variations of tested complete lubricant composition used as part of a test 

15 strategy. Figures 7 and 8 each depict variations in a tree structure. In Figure 

16 7, node 710 represents a root node or the top node in a sub branch of a larger 

17 tree structure. Node 710 has child nodes 720, 725, and 730, and each of 

18 those nodes may have child nodes as with nodes 735 and 740. Each child 

19 node is a modification of the lube composition stored in its parent node. 

20 Figure 8 depicts a similar tree structure. Figure 8 additionally depicts what the 

21 change is between nodes. For example, the transition from Default Variant 

22 node 810 to Boosted Variant 1 node 825 is the addition of Boostl 815. The 

23 transition from Default Variant node 810 to Boosted Variant 2 node 830 is the 

24 addition of Boost2 820. Each boost may represent the addition or the 

25 increase of a component designed to overcome some deficiency in the lube 

26 composition as needed to pass a particular test in the test strategy. 
27 

28 Each tree structure of variants is preferably tested by Compliance Analysis 

29 module 1 75 (Figure 1 ) to assure the tree complies with the Codes of Practice 

30 180 (Figure 1). These Code of Practice are lube industry, governmental, 

31 and/or OEM set rules which govern what mid-test program changes may be 

32 made in a lube composition without being required to repeat already 

33 successfully completed tests. 
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1 Figures 9-1 7 depict in one embodiment a schematic process logic flow 

2 diagram for use in the strategy simulator aspect of the invention. As discussed 

3 above a benefit of the system of the invention is automated changing of the 

4 lube variant used in the tests to better progress to a pass on all tests. As 

5 shown in the lube variant trees in Figures 7 and 8, there can be many variants 

6 as part of a test strategy. Tests or portions of test programs can be 

7 performed in parallel. Therefore, algorithms are necessary to address 

8 handling of the process flow during a test program. Figures 9-1 7 address this 

9 issue in various illustrative embodiments. 
10 

1 1 Figure 9 depicts process logic flow for general strategy execution. Separate 

12 lines from parallel blocks 905 are separated 910 and executed by line 915 or 

1 3 by block 930. Where result line or block 920 and 935, respectively, either fails 

14 925, if passes then another separation of line and block occurs 940 and the 

15 process is repeated until all lines have passed 945. 
16 

17 Figure 10 depicts process logic flow for individual line processing. Start by 

18 processing the line with current variant 1005 and the result line 1010 either 

1 9 passes 1 065, is a clear fail 1 01 9, or border line fail 1 01 7. Where a clear fail 

20 1019, change the variant to appropriate line clearfail variant and verification of 

21 Codes of Practice ("CoP") 1040, then return tests which are not accepted by 

22 CoP 1045, process line with the clearfail variant 1050, and determine in block 

23 1 055 if the result line passes 1 065 or fails 1 060. 
24 

25 Figure 1 1 depicts process logic flow for processing an individual line with a 

26 given variant. Begin by initializing an array of results 1 105, then sampling test 

27 properties stored in the first line of array property/trial 1110, and then analyze 

28 by decision procedure 1115. Then the result procedure 1 1 20 determines 

29 pass 1125 or fail 1135. If fail, then if number of repeats not yet exceeded then 

30 sampling test properties stored in the follow line of array property/trial 1 130, 

31 then return to analyze by decision procedure 1115 and repeat as before until 

32 either pass 1 125 or exceed number of allowed repeats 1 140. 
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1 Figure 12 depicts process logic flow for Array of Result Decision Procedure 

2 with no - Multiple Test Acceptance Criteria ("MTAC"). Begin with comparison 

3 between each property result of last line and its property limit 1205, if limit not 

4 exceeded then pass 1215, else then comparison between each property 

5 result of last line and all it's property border line fail limit 1 120. If limit 

6 exceeded 1225, then clear fail 1235, else border line fail 1230. 
7 

8 Figure 13 depicts process logic flow for Array of Result Decision Procedure 

9 (with MTAC). Begin by determining number of lines in array property/trial 

10 1305. If one line then make comparison between each property result of last 

11 line and its property limit 1310. If two lines then make comparison between 

12 mean of each property result of last line and its property limit 1315. If more 

13 than two lines then elimination from one line and make comparison between 

14 mean of each property result of last line and its property limit 1320. In the 

15 MTAC context, if more than 2 runs of the same oil are executed in the same 

16 engine test, results must be averaged using the appropriate MTAC rules 

17 applying to a given situation. In the case above, the 2 best results are 

18 considered only for averaging. E.g., the PQ engineer decides to repeat a VG 

19 four times on the same oil. The final result for this test will only be based on 2 

20 of those 4 runs and possibly those 2 leading to an MTAC averaged pass. This 

21 only applies in the US for programs carried under the ACC and API codes of 

22 practice. 
23 

24 After any of above comparison steps, then determine if limit exceeded 1325. 

25 If not then pass 1 330. if exceeded, then count number of lines in array 

26 property trial 1335. 
27 

28 If one line then make comparison between each property result of last line 

29 and its property border line fail limit 1340. If two lines then make comparison 

30 between mean of each property result of last line and its property border line 

31 fail limit 1 345. If more than two lines then elimination from one line and .make 

32 comparison between mean of each property result of last line and its property 

33 border line fail limit 1350. After any of above comparison steps, then 
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1 determine if limit exceeded 1325. If not then pass 1330. if exceeded, then 

2 count number of lines in array property trial 1335. 
3 

4 Figure 14 depicts process logic flow for Individual Test Sampling. Begin by 

5 creation of line array of results property/trial 1405, then test model 1410. If 

6 using linear test model 1440, then do sampling 1430. If using Bayesian 

7 network 1442, then do Bayesian network calculator 1415. If using Neural 

8 network 1445, then use neural network calculator 1435. After any of above 

9 steps, then test property result 1420, then filling new line of array 1425. 
10 

1 1 Figure 1 5 depicts process logic flow for pass/fail decision for Parallel Tests 

12 (ExecOr). As an overview, this process flow diagram relates to 2 or more 

13 tests run in parallel. The program simulation moves to the next step as soon 

14 as one of the 2 tests is a pass: e.g., one can run the same test A at 2 different 

1 5 labs roughly at the same time. As soon as it is known one of them passed the 

16 other one is terminated and the program moves to the next step. Now the 

17 process flow is described with reference to the Figure 15. Begin ExecOr 1505, 

1 8 then if line gives pass 1 51 0 of one or more then pass 1 51 5, if not then test if 

1 9 line gives border line fail 1 520. If not then change variant to clear fail variant 

20 for this line and verify CoP 1540, then process line with new variant 1545. 
21 

22 If passes, then pass 1535. If fail, then either repeat change variant step 1 540 

23 if fails but another line gives clear fail 1 547, or fail 1 550 if fails and no more 

24 line gives clear fail 1 555. If one or more line gives border line fail 1 520, then 

25 change variant to border line fail variant for this line and verify CoP 1 525, then 

26 process line with new variant 1530. If passes, then pass 1535. if fails but 

27 another line gives border line fail 1532, then repeat change variant step 1525. 
28 

29 Figure 16 depicts process logic flow for pass/fail decision for Parallel Tests 

30 (ExecAnd). As an overview, like the "ExecOr" process flow, this process flow 

31 diagram relates to 2 or more tests run in parallel. The difference with ExecOr 

32 is that in this case, all the tests being run in parallel in this step must pass 

33 before the program moves to the next phase, e.g., typically one would run 
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1 tests A, B and C in parallel and the program would not move to the next step 

2 before all three tests are pass. Now the process flow is described with 

3 reference to the Figure 16. Begin ExecAnd 1605 for, then if line gives pass 

4 1610 for all then pass 1615, if not then test if line gives border line fail 1620. If 

5 not all then change variant to clear fail variant for all lines and verify CoP 

6 1640, then process block with new variant 1645. If all lines pass, then pass 

7 1635. If a line does not pass, then fail 1650. If all lines give border line fail 

8 1 620, then change variant to border line fail variant for all lines and verify CoP 

9 1625, then process block with new variant 1630. If passes, then pass 1635. 
10 if a line does not give pass then go to change variant step 1640. 

11 

12 Figure 17 depicts process logic flow for Code of Practice Decisions. Begin 

13 with Variant change not accepted by CoP for one test 1705, then initialized an 

14 array of results 1710, then sampling test properties stored in the first line of 

15 array 1715, then analyze by decision procedure 1720, an check result 

1 6 procedure 1 725. If passes, then pass 1 730. If fails, then check if number of 

17 allowed repeats is exceeded 1740. If yes, then strategy execution fail 1745. 

18 If no then sampling test properties stored in the follow line of array, and then 

19 repeat from analyse by decision procedure step 1720. 
20 

21 Figures 18-28 depict in one embodiment a graphical user interface for some 

22 aspects of the system of the invention. 
23 

24 Figure 18 depicts an illustrative high level menu for the model building aspect 

25 of the invention. Figure 19 depicts an illustrative data display. Figure 20 

26 depicts an illustrative use interface regarding indices. Figure 21 depicts 

27 another illustrative view of the indices user interface. Figures 22-25 depict an 

28 illustrative user interface views for selecting specifications and tests for 

29 defining models. Figures 26-27 depict illustrative user interface views for 

30 execution. Figure 28 depicts an illustrative user interface view for program, 

31 edit objects. 



-21 - 



1 M. Other Implementation Details 
2 

3 1. Terms 

4 

5 The detailed description contained herein is represented partly in terms of 

6 processes and symbolic representations of operations by a conventional 

7 computer and/or wired or wireless network. The processes and operations 

8 performed by the computer include the manipulation of signals by a processor 

9 and the maintenance of these signals within data packets and data structures 

10 resident in one or more media within memory storage devices. Generally, a 

1 1 "data structure" is an organizational scheme applied to data or an object so 

12 that specific operations can be performed upon that data or modules of data 

13 so that specific relationships are established between organized parts of the 

14 data structure. 
15 

16 A "data packet" is type of data structure having one or more related fields, 

17 which are collectively defined as a unit of information transmitted from one 

18 device or program module to another. Thus, the symbolic representations of 

19 operations are the means used by those skilled in the art of computer 

20 programming and computer construction to most effectively convey teachings 

21 and discoveries to others skilled in the art. 
22 

23 For the purposes of this discussion, a process is generally conceived to be a 

24 sequence of computer-executed steps leading to a desired result. These 

25 steps generally require physical manipulations of physical quantities. Usually, 

26 though not necessarily, these quantities take the form of electrical, magnetic, 

27 or optical signals capable of being stored, transferred, combined, compared, 

28 or otherwise manipulated. It is conventional for those skilled in the art to refer 

29 to representations of these signals as bits, bytes, words, information, data, 

30 packets, nodes, numbers, points, entries, objects, images, files or the like. It 

31 should be kept in mind, however, that these and similar terms are associated 

32 with appropriate physical quantities for computer operations, and that these 
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1 terms are merely conventional labels applied to physical quantities that exist 

2 within and during operation of the computer. 
3 

4 It should be understood that manipulations within the computer are often 

5 referred to in terms such as issuing, sending, altering, adding, disabling, 

6 determining, comparing, reporting, and the like, which are often associated 

7 with manual operations performed by a human operator. The operations 

8 described herein are machine operations performed in conjunction with 

9 various inputs provided by a human operator or user that interacts with the 
10 computer. 

11 

12 2. Hardware 

13 

14 It should be understood that the programs, processes, methods, etc. 

1 5 described herein are not related or limited to any particular computer or 

16 apparatus, nor are they related or limited to any particular communication 

1 7 architecture, other than as described. Rather, various types of general 

18 purpose machines, sensors, transmitters, receivers, transceivers, and network 

19 physical layers may be used with any program modules and any other 

20 aspects of the invention constructed in accordance with the teachings 

21 described herein. Similarly, it may prove advantageous to construct a 

22 specialized apparatus to perform the method steps described herein by way 

23 of dedicated computer systems in specific network architecture with hard- 

24 wired logic or programs stored in nonvolatile memory, such as read-only 

25 memory. 
26 

27 3. Program 

28 

29 In the preferred embodiment where any steps of the present invention are 

30 embodied in machine-executable instructions, the instructions can be used to 

31 cause a general-purpose or special-purpose processor which is programmed 

32 with the instructions to perform the steps of the present invention. 

33 Alternatively, the steps of the present invention might be performed by 
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1 specific hardware components that contain hardwired logic for performing the 

2 steps, or by any combination of programmed computer components and 

3 custom hardware components. 
4 

5 The foregoing system may be conveniently implemented in a program or 

6 program module(s) that is based upon the diagrams and descriptions in this 

7 specification. No particular programming language has been required for 

8 carrying out the various procedures described above because it is considered 

9 that the operations, steps, and procedures described above and illustrated in 

10 the accompanying drawings are sufficiently disclosed to permit one of 

1 1 ordinary skill in the art to practice the present invention. 
12 

13 Moreover, there are many computers, computer languages, and operating 

14 systems which may be used in practicing the present invention and therefore 

15 no detailed computer program could be provided which would be applicable to 

1 6 all of these many different systems. Each user of a particular computer will be 

17 aware of the language and tools which are most useful for that user's needs 

18 and purposes. 
19 

20 The invention thus can be implemented by programmers of ordinary skill in 

21 the art without undue experimentation after understanding the description 

22 herein. 
23 

24 4. Product 

25 

26 The present invention is composed of hardware and computer program 

27 products which may include a machine-readable medium having stored 

28 thereon instructions which may be used to program a computer (or other 

29 electronic devices) to perform a process according to the present invention. 

30 The machine-readable medium may include, but is not limited to, floppy 

31 diskettes, optical disks, CD-ROMs, and magneto-optical disks, ROMs, RAMs, 

32 EPROMs, EEPROMs, magnet or optical cards, or other type of 

33 media/machine-readable medium suitable for storing electronic instructions. 
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1 Moreover, the software portion of the present invention may also be 

2 downloaded as a computer program product, wherein the program may be 

3 transferred from a remote computer (e.g., a server) to a requesting computer 

4 (e.g., a client) by way of data signals embodied in a carrier wave or other 

5 propagation medium via a communication link (e.g., a modem or network 

6 connection). 
7 

8 5. Components 

9 

10 The major components (also interchangeably called aspects, subsystems, 

1 1 modules, functions, services) of the system and method of the invention, and 

12 examples of advantages they provide, are described herein with reference to 

13 the figures. For figures including process/means blocks, each block, 

14 separately or in combination, is alternatively computer implemented, computer 

15 assisted, and/or human implemented. Computer implementation optionally 

16 includes one or more conventional general purpose computers having a 

1 7 processor, memory, storage, input devices, output devices and/or 

18 conventional networking devices, protocols, and/or conventional client-server 

19 hardware and software. Where any block or combination of blocks is 

20 computer implemented, it is done optionally by conventional means, whereby 

21 one skilled in the art of computer implementation could utilize conventional 

22 algorithms, components, and devices to implement the requirements and 

23 design of the invention provided herein. However, the invention also includes 

24 any new, unconventional implementation means. 
25 

26 6. Web Design 

27 

28 Any web site aspects/implementations of the system include conventional 

29 web site development considerations known to experienced web site 

30 developers. Such considerations include content, content clearing, 

31 presentation of content, architecture, database linking, external web site 

32 linking, number of pages, overall size and storage requirements, 
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1 maintainability, access speed, use of graphics, choice of metatags to facilitate 

2 hits, privacy considerations, and disclaimers. 
3 

4 7. Other Implementations 

5 

6 Other embodiments of the present invention and its individual components will 

7 become readily apparent to those skilled in the art from the foregoing detailed 

8 description. As will be realized, the invention is capable of other and different 

9 embodiments, and its several details are capable of modifications in various 

10 obvious respects, all without departing from the spirit and the scope of the 

1 1 present invention. Accordingly, the drawings and detailed description are to 

12 be regarded as illustrative in nature and not as restrictive. It is therefore not 

13 intended that the invention be limited except as indicated by the appended 

14 claims. 
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